The present invention relates generally to a computer system for quickly and consistently producing printed materials. More specifically, the present invention relates to an automated technique for converting a PostScript file to a PDF file.
The existing methods of procuring printed business materials are characterized by cumbersome and labor-intensive procedures. These procedures carry with them certain inefficiencies and are often prone to error. For the majority of small to medium sized printers, the printing of business cards and stationery entails a time-consuming series of steps which generally must be repeated every time a new order is placed.
Referring to FIG. 1, a representative block diagram 100 is shown of certain steps that might be used to procure an order by a customer. While the order might consist of any textual or graphical material, a business card example is used throughout to facilitate discussion. In general, an administrator in an organization first collects data from the employee who desires the business cards. Such data includes name, title, telephone and facsimile numbers, mobile telephone number, e-mail address, etc. This data then gets sent via telephone or facsimile to the printer as shown in step 102. The printer typesets the information in step 104, and then sends back a proof to the administrator in step 106. The administrator then typically sends the proof to the employee for verification, and receives the returned proof with marked-up corrections. The proof is then sent back to the printer in step 108. The printer typesets the corrections in step 110 and sends the proof back to the customer in step 112. Steps 108-112 might be repeated several times until the customer approves the proof in step 114. After the order is final, the printer must go through several additional steps before the order is printed. For instance, the customer service department might enter the job into the printer""s internal tracking and billing system. The job then goes to the prepress department in step 116 which reproduces the content into a format so that it is ready to print. The manufacturing process is applied in step 118 and the order is printed.
Getting through this series of steps with the printer usually takes several days. Typically, seven to ten days after this process is completed, the cards are received by the employee who ordered them. Because each job is entered manually, a new order for a similar customer may not look precisely like the last one. Add the complexities of a multi-location organization (with many employees) and a relatively simple product purchase can become very complex.
Moreover, the printing of more complex items, such as full color pamphlets and brochures, results in many more iterations between the design agency, the customer and the prepress department. The iterations due to color correction and perfection of all design elements likely results in even more time required to complete the product. Despite the iterative steps described above, it is estimated that 15% to 30% of print jobs for traditional business materials arrive at the customer with errors. The propensity for errors and the general lack of consistency produced using the traditional process is due in large part to the manual nature of the task. At each step in the process the file may be opened and manipulated repeatedly, which introduces new opportunities for errors and inconsistencies.
FIG. 2 illustrates a prior art block diagram 200 of representative steps in the process and describes potential problems that may occur.
The process begins with a customer providing the print vendor with the information on the product to be composed. The customer will typically provide the information on an order form, make annotations to a physical sample, and/or communicate the data verbally. The print vendor""s job is to create a layout of the print product for the customer to preview and approve. The print vendor will typically interpret the customer""s information and compose a preview layout of the product in a publishing tool such as Pagemaker or Quark XPress. In FIG. 2 this is shown by the print vendor computer 202 creating a preview layout file 206.
Unfortunately, this task is made more complicated by a common practice called xe2x80x9cmasteringxe2x80x9d. To control costs in printing, it is common to pre-print or xe2x80x9cmasterxe2x80x9d stock in bulk with certain static elements. In many cases the static elements are xe2x80x9cspot colorxe2x80x9d or xe2x80x9cprocess colorxe2x80x9d graphics (while the variable information is usually in a single color, often black). In order to provide a preview of what the printed product will actually look like, the preview layout must contain both the variable information and the mastered elements. Once the preview layout is completed, it is then printed and sent to the customer for their approval.
The customer then reviews the facsimile of the proof, annotates any changes, sends the proof back to the vendor via facsimile and/or communicates the changes to the vendor verbally. Once the customer approves the preview layout, the vendor begins the prepress process. It is important to note that the xe2x80x9cpreviewxe2x80x9d that the customer is approving is a facsimile copy of a low-quality printout. Because the quality is so low, it is possible (even under the best of conditions) that the final printed product may look slightly different from the proof that the customer approved. If the customer is very demanding, these differences may not be acceptable and will require that the vendor re-print the order.
A number of available software tools can be used by a human operator to create, review, and edit EPS files. However, EPS files that ultimately are output from products such as Illustrator, Quark, Pagemaker, or Photoshop all have certain differences, or eccentricities, which are difficult to account for and process on a consistent basis. Also, they do not ensure referential integrity or consistent settings for color in such files. Some checking may be done to analyze and detect problems in EPS files, however, such checking does nothing to fix or standardize an output EPS file. In addition, as described below, each time a human operator must open a file manually and review it using a particular software program there is the potential for errors to be introduced into the file.
Step 208 in FIG. 2 shows the next process step of composition. In particular, now that the customer has approved the preview, the vendor must create a layout that is suitable for printing. To do this, all of the mastered elements that were included in the preview layout must be removed. This means that the vendor must open the preview layout file and manipulate the file data manually by hand. This is problematic, however, because the vendor is changing a file (or data structure) that the customer has already approved. It is possible that alterations will be made, either intentionally or accidentally, that will change the content or appearance of the product when it is finally printed. The result is the print layout file 210, as so modified.
The errors that can occur are numerous and varied. Even simple procedures can result in major problems. One simple example is the use of xe2x80x9ckeyboard shortcutsxe2x80x9d. Many professionals use a series of keyboard shortcuts (as offered by various programs) instead of a mouse to save time in performing simple tasks. These shortcuts typically require the user to press a modifier key (such as xe2x80x9cALTxe2x80x9d or xe2x80x9cCTRLxe2x80x9d) and then press the desired shortcut key. Sometimes, however, the user will mistype and accidentally end up inserting text into a document inadvertently. For example, if the user is trying to cut a graphic or piece of text from a document, the user might use the keyboard shortcut for xe2x80x9ccutxe2x80x9d (CRTL-X). If the user fails to fully depress the CTRL key, the letter xe2x80x9cxxe2x80x9d will be inserted into the document. While this a relatively straightforward problem, such mistakes might not be detected until late in the process. This might require the vendor to re-print the product, which is expensive and time-consuming. Hence, any reduction in the overall risk of introducing human intervention into the process would be advantageous.
As another representative example, the act of opening the file can lead to the common problem of xe2x80x9cfont substitution.xe2x80x9d Note that the preview layout file does not (generally) contain the font data necessary to display the text. To save space, the file simply refers to a font file that is stored on the computer used to open the document. If the computer does not have one or more of the fonts referred to by the preview layout file, the closest possible match will generally be substituted from the fonts available. This is known as xe2x80x9cfont substitution.xe2x80x9d Publishing programs may not inform the user that font substitution is taking place. If the user does not notice the swap, the substituted fonts will be saved with the new document.
When the vendor finally exports the data as a PostScript file for printing, the file will refer to the substituted fonts, not the original fonts. Sometimes the substituted fonts are very similar to the correct fonts, so they might look fine. However, in many cases the substituted fonts are significantly different, causing the final printed product to look vastly different from the preview. Typical problems range from low impact results (e.g., the text looking slightly different), to severe differences (e.g., the text wrapping onto multiple lines, the text coming out completely garbled, etc.). Because final proofing will not be done until later in the process, these problems are often very costly to fix when (and if) they are eventually found.
Trapping is a printing process used to adjust areas where two distinct colors meet so that press mis-registration will not cause white specks. Trapping can also be done during the proofing process. It would occur after layout of the product was accomplished, after graphic elements had been identified and placed, and after variable data (name, telephone, address, etc.) had been identified and placed. Trapping involves specific manipulation of certain areas in the file. As in composition, if the file is manually manipulated there is the potential for error. The trapping process produces a trapped file 207.
Step 212 next shows the imposition being performed and is used to create an imposed layout file 214. Imposition is the process of preparing the print layout for production on a press. The main goal of imposition is to arrange multiple pages and/or images in the proper order for efficient printing. For example, it is far more efficient to impose four or more business cards onto a single plate than to print each business card individually. The imposition process also requires the addition of elements such as crop marks, registration marks, fold marks, color bars, die marks, and the like to the original print layout file. Imposition can be performed manually or via an automated program. Again, manually opening the file to perform imposition can lead to problems.
Color separation, as shown in step 216, is the process of separating a color image into a series of single color images that will be used to produce plates. When each single-color plate is printed on top of one another, the result is a composite color image. The color separation step produces a color separated file 218.
Color separation is performed previous to raster image processing (RIP). An imposed layout file must be color separated prior to the RIP, which means that the vendor must use another software program. In such cases, errors including font and graphic substitution can occur just as they did in the composition and imposition stages.
Once a file is imposed and color separated (plate file) is it is ready for processing by a RIP 224. There are many techniques used to create PostScript files. Depending on the workflow employed by the print vendor, the PostScript file may include font subsetting as well as OPI comments that are processed by the RIP device. In either of these cases, it is possible to introduce font and graphic substitution errors. The output from the RIP (which is generally a rastered file) is sent to an output device 226, which might include a recorder or image setter. The output device 226 places the image on a medium to be used by the press device 228. Alternatively, the binary file 230 could be received directly by a digital press device 232 for printing.
Based upon the above-described problems with the traditional process, different prior electronic solutions have been proposed. While such solutions have attempted to solve the consistency problem in processing a print job, they have generally proven to be insufficient. Below are detailed certain example solutions, and problems associated with each solution.
One proposed solution includes attempting to automate the process of preview and print layout generation by writing custom plug-ins to commercially-available publishing programs such as Quark XPress or Adobe PageMaker. One drawback to this solution is that the modified software cannot generally keep track of which elements in a layout are mastered and which are not. This means that at least two PostScript files must be generated, one for the preview layout and one for the print layout. Also, the modified software lacks the ability to store special production information in the PostScript file, such as ink codes, stock information, and other details. The overall solution therefore relies on humans to properly recall this information, or the solution must retrieve such information from yet another document, without any assurance of the accuracy of the production information in the other document. Moreover, these systems do not maintain a reference for standard corporate design or procurement rules for printed matter, and as such are prone to error and not susceptible to automated validation.
Another solution involves using Open Prepress Interface, or OPI. The OPI Specification 1.3 from Adobe Corporation defines the Open Prepress Interface as a collection of PostScript-language comment conventions that allows a page-layout program to use low- or medium-resolution TIFF images for layout and proofing, and have a prepress system or OPI server automatically substitute a high resolution TIFF or other image when the final film or plates are generated. Both desktop prepress software and high-end prepress systems can use OPI comments to minimize network traffic and image storage requirements.
Certain functionality is desired, however, which OPI does not inherently provide. Example of such drawbacks include the following. OPI does not generate preview or print layouts. It simply provides a low-resolution file for display on screen and then provides a high-resolution counterpart that is used when it comes time to print. Also, OPI itself cannot determine whether the system is printing the preview layout or the print layout. Moreover, even if OPI could discern which layout it is printing, it lacks the logic to decide which image to use in which situation. Further, OPI only works for graphic images; it cannot be used to control text data.
Still other processes have tried to solve the consistency problem by using a simple Internet solution. Such solutions involve an on-line web site for product ordering that also generates a low-resolution bitmap of preview images that are displayed to the customer at order time for approval. One drawback of these solutions is that their bitmap file formats are unable to differentiate between mastered and non-mastered elements such as graphics or text, so the system must generate one low-resolution bitmap image for preview and another high-resolution image for the other stages of the production process. Also, the bitmap images used in these solutions cannot store production-specific information such as ink codes, stock information, and other details. Hence, such solutions generally reproduce the problems associated with the traditional process, but in a computer-controlled environment.
Still another solution might involve an implementation using some form of programming language. PostScript (for instance) is a programming language for imaging devices. Many solutions propose using some form of PostScript programming. However, it should be noted that the PostScript language, by itself, does not constitute a complete solution to the aforementioned problems. For example, the PostScript language does not contain any concept that differentiates between preview and print elements and cannot automatically solve the problems with consistency in the print process.
As mentioned above, when a human operator manually runs a prepress application to process a file there is a great potential for error. For one, because of the subjective nature of the process, the operator may inadvertently make a mistake. Also, similar printed materials may not be consistent because the operator may unknowingly use different settings when a job is processed over and over again. There is no standard format or automated way for the operator to save particular settings for a job to be run under a certain prepress application. In general, there is a need for more certainty, consistency, and standardization in the use of prepress software applications. Customers could also benefit from a system and technique that would provide greater scalability and greater speed in the processing of printing orders.
In particular, converting a PostScript file to a PDF file is a prepress application that could benefit from the above. Converting PostScript to PDF is a printing process used throughout the prepress industry to produce smaller file sizes, to produce standard image output, and to perform proofing. When a PostScript file is converted to PDF a new output file is created holding the PDF output. The new file is output according to the user interface options selected in third party applications, or according to exposed API parameters in the third party applications. The resultant PDF file produced can hold all PostScript data in a significantly smaller file by using the simpler more defined PDF.
When a PostScript file is converted to PDF there are many decisions to be made for the output of the file. Some of these include preserving OPI comments, preserving overprint settings, preserving halftone information, downsampling of raster images (dpi and bit depth), embedding fonts and subsetting of fonts.
A number of available software tools can be used by a human operator to convert PostScript files to PDF, including the creation, review and editing of the resultant PDF file. Some of these tools have exposed proprietary APIs that can be used to control them. PDF files generated by software tools such as Quark, Adobe Photoshop, Illustrator, Distiller and Freehand each have their own quirks and eccentricities. Settings of parameters (such as preserving OPI comments, preserving overprint settings, preserving halftone information, downsampling of raster images (dpi and bit depth), embedding fonts and subsetting of fonts) for these applications are all set through proprietary user interfaces in each product. Conversion settings specified by human hands introduces the possibility for errors in the process as each conversion is variable according to the user""s choice. Also, conversion can take a variable length of time (possibly hours) depending on which settings are used, any changes needed, any proofing, etc., and human intervention is needed to oversee and drive all steps in the conversion process.
Therefore, it would be desirable to have a system and technique that would remedy many of the above problems associated with manual conversion of files in the printing process.
In response to aforementioned costly, cumbersome and error-prone environment, the present invention utilizes certain technology, along with an interface medium such as the Internet, to offer a fully automated, efficient and cost-effective solution for producing print jobs and the like. The present invention reduces the number of times that human intervention is required in the process and thereby reduces labor intensity, labor cost, time, and high error rates.
In particular, a PostScript to PDF conversion prepress application is hosted on a server and is automated to provide consistent, error-free and rapid conversion of files used in the printing process. Conversion of a PostScript file is accomplished using a PostScript to PDF conversion subsystem. This subsystem includes the master farmer service and a conversion module. A client application such as the product setup module requests that input PostScript files be converted. Conversion parameter settings for the client application are pulled from the image logic information database (ILIAD). The client application communicates to the master farmer service the conversion job, which is forwarded to the conversion module.
Conversion of PostScript files is done using the Farm service in a conversion module that automates a third party prepress conversion application. The conversion module uses Adobe""s Distiller software tool to actually perform the automated conversion. The conversion module accepts multiple parameters holding conversion specific information, then uses Distiller to actually perform the conversion. These parameters passed to the conversion module hold the decisions for the conversion of the PostScript file to PDF. The Farm service then outputs the resultant PDF file. The client application continuously polls the Farm service for status of the individual conversion jobs.
One advantage of the present invention is that automated conversion is performed. PDF files are produced automatically by a hosted server application in an automated prepress management system that is highly scalable. Also, standard, consistent, files are produced. Exact settings are stored and retrieved from a database for the conversion process to produce consistent results for similar jobs. No human intervention is needed to convert files.
The present invention provides numerous other advantages. For one, by hosting a prepress application on a server, the prepress application can be invoked automatically by any of a variety of client applications (such as the product setup module, proofing module, web server, plater service, etc.) as part of a complete printing system. No human intervention or manipulation of a file is needed which greatly reduces errors. In addition, the turnaround time for a printing job is greatly reduced. Also, the use of washing during customer setup and the product certification process means that errors are further reduced. Secondly, the ability to save and reuse parameter values for particular prepress application means that similar jobs for a client will be output in consistent form. In specific embodiments, default parameter values may be hardcoded into the specific module that runs the prepress application (such as the trapping module, imposition module, etc.) so that the application is run consistently with respect to those parameters. Also, any job parameters determined at run time by either the customer or the entity executing the system are stored in the image logic information database (ILIAD) for future use. For example, a decision made with respect to the look of a business card is stored in the database and reused, thus producing a consistent output for future business card orders. Output is consistent for the same jobs run over and over again. Thirdly, the system is also highly scalable. Hosting a prepress application on a server means that more servers and/or more applications can be added as the need arises. The Farm system as described herein provides an environment where servers and/or modules can be added as required.
In order to eliminate the numerous opportunities for error that appear in the many stages of the traditional print process, in one particular embodiment the present invention utilizes a single electronic file format, a xe2x80x9cPrint Ready Filexe2x80x9d (PRF) format, that can be used at all stages of the process. This format provides the ability to tag certain elements to indicate whether they should be included in the preview layout, the print layout, or both. At each stage, the software programs that read and process the information check these tags to determine the exact content required at that stage.
The Print Ready File has each element precisely mapped. Because no human is required to alter it, the data for the product and the location of its elements need not change. This eliminates a large source of human error. Additionally, because the present system uses the PostScript language (or its equivalent), the present system does not necessarily need to employ commercial page layout software. The present system allows the font and graphic information to be embedded directly into the file. This eliminates errors, including the font and graphic substitution errors common to the traditional process. Thus, a single file contains all of the data needed for the entire process. The file that the customer previews is the same file that is sent to the vendor (or ultimately the printer). This leads to consistency throughout the life of a print order, and provides for extremely low error rates overall.
According to one aspect, an Internet site is used to provide a printing service embodying the present invention. Once a particular customer job is set up, the customer can modify, order, proof, and control its printed and graphic materials. The solution provided by the present invention helps to eliminate the back and forth process between the customer and the printer.
Resulting features of the overall system include, but are not limited to, the following: (1) The system contains all of the data the customer needs in order to print the customer""s materials. (2) Data are completely secure and is the property of the customer. (3) The system incorporates rules to ensure that no matter which party might happen to input data, the resulting printed materials are printed in a manner consistent with the corporate image and design policies that have been approved. (4) The system incorporates a variety of business logic, including procurement, authorization security and billing rules defined by the company. These rules set up an authorization process whereby an employee puts in an order and it is routed to the authorized party. The purchasing administrator then releases the particular order to be sent to the printer.